The CICA Windows Explosion!/The CICA Windows Explosion! - Disc 2.iso/programr/wtj009.zip/TOOLBAR.ZIP/README.1ST

Text File | 1992-09-03 | 6KB | 125 lines

TOOLTEST.EXE - A simple test platform for testing compiled
toolbars. Allows the designer to see the toolbar(s) in
action and see the generated return codes. This will be
yours to publish on Compuserve/supplemental disks if you
like.

TOOLTEST.RES - Swap compiled toolbars and bitmaps into this
file and "rc tooltest.res" to test your own toolbars.

TC.EXE - The DOS portion of the toolbar. Compiles .tb (text)
files into .tbr (binary) & .rc (Microsoft script) or
optionally, directly into .res files.

TOOLTST*.TB - The script files that generated the toolbars
currently in the ToolTest application.

readme.1st - this file

Tutorials!

TOOLTEST.EXE
     Run ToolTest under windows to see some toolbars in
action. Up to three toolbars can be tested at one time but
must be named "tooltest1", "tooltest2", & "tooltest3" of
type "toolbar". If less than three toolbars exist in the
resource, the toolbar function will display a warning but
the program will function normally.
     The Toolbar menu selects the active toolbar (toolbars
that don't exist will be grayed) on which all the other
functions will act. Note that although a toolbar may be
"active" it is not visible until a master set is activated.
     Activate master sets from the Master menu, not all
toolbars have three sets (this is user defined but hard-
coded in the test program, hey it's a simple program...)
     Press tools to see the action. Hierarchical tool bring
up slave tools, non-hierarchical tools return notifications
codes as do all slave tools. Use the Special menu to display
return codes.
     Slave sets can also be displayed manually by the
application; to try this, use the Slave menu.
     Tools can optionally be "unpressed" by the application
(default) under Special. (Master tools can also be unpressed
but since they usually show the state of the application,
ToolTest leaves them pressed.)
     Try out Save State & Restore State (implemented for MDI
applications which may have a different toolbar context
saved for each type or state of the MDI child.)
     With a flexible number of master sets, most
applications won't ever need to load more than one toolbar
resource, but if they wanted two active at a time, say, or
different numbers of cells or tool sizes, it's very simple.


TC.EXE
     The compiler usage: type 'rc /?' if you forget. The
extension for the input file is '.tb' by default.

'tc mytools'
     Generates mytools.tbr & mytools.rc from mytools.tb.
Mytools.rc can then be appended to your normal scriptfile
and compiled into the .exe with the other resources. (rc
must be able to find mytool.tbr)

OR

'tc -r mytools'            [the easy way]
     Generates mytools.res from mytools.tb. It is then
easiest to copy mytools.res into tooltest.res (for example)
using a resource mover like Whitewater Resource Toolkit (be
sure to rename the resource to "tooltest1", 2, or 3 to use
with tooltest.exe or change name directly in .tb script
first line.
Then add the resulting .res file (tooltest.res) into the
.exe with 'rc tooltest.res'. Keep in mind that the Windows
toolbar function will retrieve not only the toolbar resource
but also all bitmap resources named in the toolbar resource
so they must also reside in the .res (& resulting .exe)
however unlike the Levaro toolbar, the "pressed" state of
the bitmap (as well as all bevels) are created by the
toolbar. You need only one bitmap per tool, lt. gray
background, whose size is specified in the toolbar script.


Script Files:
     Look at tooltst1, 2, & 3 (and other neat examples in
4 & 5) to see the scriptfiles that created the tooltest
toolbars. Also see sample.tb for a commented example
(although comments are fine in the scriptfile, this won't
compile due to a sample error).

Well, there's a little taste of the toolbar. Listed below
are a couple of features I'd like to add but the length of
the code (sans headers) is about a thousand lines now (about
evenly distributed between compiler & toolbar Windows
library) and you would be the best judges of which of the
following features to add (if any). Please take a quick look
after you've played with the toolbars a little:
     The script line '..."bitmapname",102' (i.e. no
whitespace after comma) causes the '102' to be lost. This is
simply a known bug in this version.
     The script line 'TOOLSET 1' is a reference to the
programmer that this toolset will be referred to as #1
should he/she want to display a specific toolset. Currently,
the # is ignored and toolsets and assigned numbers in order.
At the very least, a warning should be generated by the
compiler if the numbers do not match. Even better, the
writer should be able to specify an arbitrary number to use
as a reference so that inserting TOOLSETs at the top would
not require 'renumbering' the script and re-coding the
parent application. Ideally, the programmer should be able
to specify 'TOOLSET MAIN_TOOLS' or some identifier which
could be read from a supplied header file that is also used
by the application. For my own use, I will probably
implement the last feature but let me know (ASAP) if you
feel it's worth the extra space. (The addition of the
warning option would be trivial).
     Currently, the toolbar is a library, not a DLL, so the
parent application must register the toolbar window class
and link in toolbar.lib. The toolbar will most likely be a
DLL in the near future so, again, let me know what your
feelings are.

That's it! Looking forward to hearing from you...
Dave
(76307,2300)